sigh, this spurs a linter error:

lib/util.js
  665:24  error  Use const Buffer = require('buffer').Buffer; at the beginning of this file  require-buffer

✖ 1 problem (1 error, 0 warnings)

cc @silverwind

You can also put this line before the requires

Still hacky, but better! Thanks @targos, I switched the order of exports.

I tried to remove the isBuffer call altogether (keep it DRY with buffer.isBuffer), but that causes another circular dependency. I think the best way forward is to move util.deprecate to an internal module.

Alright, force pushed a fix that moves deprecate() to an internal module, allowing us to circumvent the whole thing. Right now, the internal module .deprecate is still exposed through util.deprecate.

@brendanashworth #1892 should fix that eventually.

As for the linter error, you could just put /* eslint-disable require-buffer */ in worst case.

Also I wonder why no test has caught this circular dependency. util.isBuffer seems completely untested, maybe add a small test?

@silverwind hmm, looking at #1892, it would reintroduce the dep issue because the internal module references back to the util module. Do you think I should just add the linter error hack for now, have #1892 fix the cyclic issue, and call it a day? And I added a small true / false test, I too was surprised it wasn't caught by the test suite.

Added a small commit, summary:

> util.isBuffer === Buffer.isBuffer
true

I'd be fine with a hack if you denote it as such (// HACK:). #1892 still needs a bit of work.

I'd prefer to go through with these commits, without introducing a hack / linter comment, to fix the bug. #1892 shouldn't be hard to port the changes through, as the location of the code is all that changes.

True, shouldn't be too hard to have separate methods later.

LGTM, started off a CI just to be sure:

https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/17/

CI failures are unrelated. @brendanashworth can you land it?

This and 671e64a are pretty important fixes and we should probably do a quick patch release for them.

cc: @rvagg @Fishrock123 @chrisdickinson

@silverwind yes, landing now - 3806d87 seems to be important too, they were talking about a CVE.

Thank you, I've merged these commits in 671e64a...626432d, in time for #1996.